It is common in the networking field for data from a high-speed source to be transferred across a lower-speed link. It may be desirable to distribute flows from the high-speed source across multiple lower-speed physical links in a load-sharing manner. The load sharing allows the multiple lower-speed links to simulate a higher-speed physical link. For example, data flows received from a high-speed packet over SONET (PoS) source may be distributed to multiple lower-speed Ethernet links.
Mapping of data from the high-speed source to the multiple lower-speed links is typically accomplished using a hashing function. Typically, the Point-to-Point Protocol (PPP) is run over the PoS link. However, mapping is further complicated by the potential for data flows to be transmitted according to different protocols. PPP, for example, can support two commonly used network control protocols known as the Internet Protocol Control Protocol (IPCP), which is used to transport IP packets, and the Bridging Control Protocol (BCP), which is used to transport Layer-2 MAC frames. In order to ensure that all of the packets for a given flow are transmitted on the same physical link to avoid potential problems associated with packet misordering, different hashing functions are used for the different protocols.
For example, the mapping, or hashing, function for the IP packets might operate on the 5-tuple {source IP address, destination IP address, IP protocol type, source port number, destination port number}, and the mapping function for MAC packets may operate on the pair {destination MAC address, source MAC address}. In a standard PPP environment, the determination of which hashing mechanism to use can be based on the Protocol ID field of the PPP header, which identifies the packet as an IP packet or an encapsulated MAC frame.
A problem exists when packets arriving from the PoS link are encapsulated according to the MultiProtocol Label Switching (MPLS) protocol. The problem exists because the Protocol ID field of the PPP header contains a value that indicates the packet is MPLS encapsulated, and therefore does not indicate the format/type of the encapsulated packet. On a PPP link, an MPLS encapsulated packet contains a MPLS shim header that immediately follows the PPP header. The shim header contains one or more labels (referred to as the label stack) that are used to switch the packet through the network. The labels may also be used to access a label database to determine the type of data carried by the packet. However, providing access to the label database for each component of the network switch that determines the type of data carried by a packet can be cumbersome and expensive.
Note that the situation is similar for other types of high-speed sources. For example, when the source is a 10 Gbps Ethernet interface and the lower-speed interfaces are 1 Gbps Ethernet links. In the case of an Ethernet source interface, the EtherType field in the Ethernet frame is analogous to the PPP Protocol ID field. The problem is the same in both cases (i.e., the EtherType field contains a value that indicates the packet is MPLS encapsulated, and therefore does not indicate the format/type of the encapsulated packet), and the solution presented for the PoS source is also directly applicable to an Ethernet source interface.